Part 02 (이론): 1세대 Sidecar 메시의 리눅스 커널 내부 해부 (Webhook · iptables · UID 1337)

1. 미스터리 ① 해부: 누가 내 파드에 사이드카를 끼워 넣었나? (MutatingAdmissionWebhook)

1-1. 쿠버네티스 API 서버(kube-apiserver)의 4단계 입국 심사대

우리가 터미널에서 kubectl apply -f order-api.yaml을 치면, 그 YAML 설계도는 곧바로 클러스터 장부(etcd)에 저장되는 것이 아닙니다. kube-apiserver라는 본사 민원 창구 안에 있는 4단계 입국 심사대를 순서대로 모두 통과해야만 비로소 etcd 장부에 기록됩니다.

flowchart LR
    U["👩‍💻 kubectl apply
(컨테이너 1개짜리
순수 Pod YAML)"] --> AUTH["1️⃣ 인증
(Authentication)
'누구십니까?'"]
    AUTH --> RBAC["2️⃣ 인가
(Authorization / RBAC)
'파드 만들 권한 있습니까?'"]
    RBAC --> MUT["3️⃣ 변형 어드미션 웹훅
(Mutating Webhook)
🔧 '설계도 개조 수술!'"]
    MUT --> VAL["4️⃣ 검증 어드미션 웹훅
(Validating Webhook)
🔍 '개조된 최종본 합격 검사!'"]
    VAL --> ETCD["5️⃣ etcd 저장
(컨테이너 2개 +
초기화 컨테이너 1개)"]

    ISTIOD["🧠 istiod
(istio-sidecar-injector)
:443 웹훅 서버"]
    MUT -- "HTTPS 요청:
'이 Pod 개조해 주세요'" --> ISTIOD
    ISTIOD -- "JSONPatch 응답:
'istio-init 과 istio-proxy
2개를 추가하세요!'" --> MUT

각 심사대가 하는 일을 건물 건축 허가 과정에 비유해 보겠습니다.

1-2. istiod가 파드 설계도에 몰래 그려 넣는 2개의 컨테이너

우리가 Part 01에서 네임스페이스에 istio-injection=enabled 라는 라벨을 붙였을 때, 쿠버네티스의 3단계 심사대(MutatingAdmissionWebhook)는 다음과 같이 동작했습니다.

1. "part1-demo 네임스페이스에 새 파드를 만들겠다는 요청이 들어왔네? 어라, 이 네임스페이스에는 istio-injection=enabled 스티커가 붙어 있잖아!"
2. 그러자 kube-apiserver는 잠시 멈추고, istio-system에 떠 있는 istiod 파드의 웹훅 포트(443) 로 방금 받은 파드 YAML을 보내며 물어봅니다: "이 파드 설계도 어떻게 개조할까요?"
3. istiod는 0.01초 만에 "원래 있던 컨테이너는 건드리지 말고, 그 옆에 아래 두 개의 컨테이너와 공유 볼륨들을 추가로 끼워 넣으세요(JSONPatch)!" 라고 답장을 보냅니다.

그 결과 내 파드 안에는 원래 내가 적은 앱 컨테이너 외에 두 명의 요원이 추가로 탑승하게 됩니다.

flowchart TB
    subgraph POD["개조 수술이 끝난 Pod 내부 (같은 IP · 같은 네트워크 공간 공유)"]
        direction TB
        INIT["👷‍♂️ 1. 초기화 컨테이너 (InitContainer: istio-init)
• 본 컨테이너들이 켜지기 전에 가장 먼저 단독 실행됨
• 커널에 iptables 납치 규칙(15006 / 15001)만 설치하고
• 1초 만에 임무 완료 후 스스로 종료됨 (Completed)"]
        
        subgraph MAIN["본 컨테이너들 (InitContainer가 성공해야 동시에 켜짐: READY 2/2)"]
            direction LR
            APP["🛵 2. 내 비즈니스 컨테이너
(study-client 또는 echo)
• 일반 유저(UID 100 / 1000)로 실행
• 아무것도 모른 채 평범하게 통신"]
            PROXY["🛡️ 3. 사이드카 컨테이너 (istio-proxy)
• 반드시 UID 1337 계정이 부여됨!
• pilot-agent + envoy 프로세스 실행
• 15006(입구) · 15001(출구) 포트 대기"]
        end

        INIT == "① 커널 네트워크 세팅 완료 후 바통 터치" ==> MAIN
    end

1-3. 왜 istio-init 이라는 '초기화 컨테이너(InitContainer)'가 따로 필요할까요?

여기서 중요한 의문이 생깁니다.

"그냥 istio-proxy(Envoy 사이드카) 컨테이너 하나만 넣어서, 걔가 켜질 때 커널 네트워크(iptables) 설정도 같이 하면 안 되나요? 왜 굳이 1초 만에 죽는 istio-init 컨테이너를 따로 먼저 돌리나요?"

두 가지 결정적인 이유가 있습니다!

1. 첫째, 기동 순서 보장 (내 앱이 Envoy보다 먼저 패킷을 쏘는 사고 방지)
   • 쿠버네티스에서 일반 컨테이너 2개(내 앱 + istio-proxy)는 동시에 켜집니다. 누가 0.1초 먼저 켜질지 아무도 보장할 수 없습니다.
   • 만약 커널에 iptables 납치 규칙이 깔리기도 전에 내 앱이 먼저 켜져서 외부로 요청을 보내버리면, 그 첫 요청은 서비스 메시(mTLS 암호화 등)를 타지 않고 그냥 날아가 버립니다.
   • 반면 쿠버네티스의 초기화 컨테이너(initContainers) 는 "내가 완전히 실행을 마치고 성공(Completed)하기 전까지는 본 컨테이너(containers)들을 절대 깨우지 않는다" 는 100% 순서 보장 규칙을 가집니다. 따라서 istio-init이 먼저 커널 네트워크 공사를 완벽히 끝낸 뒤에야 내 앱과 Envoy가 켜집니다.
2. 둘째, 최소 권한 원칙 (보안 분리)
   • 리눅스 커널의 네트워크 길목(iptables)을뜯어고치려면 리눅스 커널의 NET_ADMIN 과 NET_RAW 라는 막강한 네트워크 관리자 권한(Capability)이 필요합니다.
   • 만약 24시간 내내 외부 트래픽을 받는 istio-proxy(Envoy) 컨테이너에게 이 NET_ADMIN 권한을 계속 들려주면, 혹시라도 Envoy가 해킹당했을 때 해커가 네트워크 규칙을 마음대로 조작할 수 있습니다.
   • 그래서 istio-init에게만 잠깐 NET_ADMIN 권한을 주어 1초 만에 iptables 규칙만 딱 깔고 사라지게(종료되게) 만들고, 정작 24시간 돌아가는 istio-proxy는 아무런 커널 관리자 권한이 없는 평범한 일반 계정(UID 1337)으로만 돌리는 것입니다!

2. 미스터리 ② 해부: 리눅스 커널은 어떻게 패킷을 가로채나? (Netfilter와 iptables)

이제 istio-init이 파드의 리눅스 커널 안에 설치하고 간 패킷 납치 장치(iptables) 를 해부할 차례입니다.

2-1. 초보자를 위한 Netfilter와 iptables 1분 개념 정리

리눅스 운영체제 안으로 네트워크 패킷이 들어오거나 나갈 때는 반드시 커널 바닥에 있는 5개의 도로 검문소를 지나가야 합니다.

2-2. 패킷이 끌려가는 2개의 길목: 입구(PREROUTING)와 출구(OUTPUT)

파드의 네트워크 방(netns) 안에는 Istio가 사용하는 두 개의 핵심 길목(Chain)이 있습니다.

1. PREROUTING (입구 검문소): 파드 바깥에서 랜선(eth0)을 타고 방금 파드 안으로 도착한 패킷이 내 앱 컨테이너에 닿기 직전에 무조건 거치는 첫 번째 관문입니다.
   • Istio는 여기에 ISTIO_INBOUND 라는 전용 검문소를 연결해 두고, 밖에서 들어오는 모든 TCP 패킷을 무조건 15006번 포트(Envoy의 virtualInbound 입구 창구) 로 꺾어 버립니다(REDIRECT --to-ports 15006).
2. OUTPUT (출구 검문소): 파드 안의 내 프로그램(curl, Python, Java 등)이 바깥으로 보내려고 방금 만든 패킷이 랜선(eth0)으로 빠져나가기 직전에 거치는 출구 관문입니다.
   • Istio는 여기에 ISTIO_OUTPUT 이라는 전용 검문소를 연결해 두고, 안에서 밖으로 나가려는 모든 TCP 패킷을 무조건 15001번 포트(Envoy의 virtualOutbound 출구 창구) 로 꺾어 버립니다(REDIRECT --to-ports 15001).

flowchart LR
    subgraph POD_NETNS["Pod 네트워크 네임스페이스 (netns) 내부"]
        direction TB
        ETH0["🔌 eth0
(파드 외부 랜선)"]
        
        subgraph KERNEL["🐧 리눅스 커널 Netfilter (iptables -t nat)"]
            PRE["1️⃣ PREROUTING 체인
(밖에서 들어온 패킷)"] --> INB["ISTIO_INBOUND
→ REDIRECT :15006"]
            OUT["2️⃣ OUTPUT 체인
(안에서 나가는 패킷)"] --> OUTB["ISTIO_OUTPUT
→ REDIRECT :15001"]
        end

        subgraph ENVOY["🛡️ istio-proxy (Envoy, UID = 1337)"]
            P15006["입구 창구 :15006
(virtualInbound)"]
            P15001["출구 창구 :15001
(virtualOutbound)"]
        end

        APP["🛵 내 비즈니스 앱
(UID = 100 또는 1000)
포트 :8080"]
    end

    ETH0 -- "외부 요청 도착" --> PRE
    INB == "강제 납치!" ==> P15006
    P15006 -- "검문 완료 후 전달
(출발지: 127.0.0.6)" --> APP

    APP -- "외부로 요청 발송
(예: order-api:80)" --> OUT
    OUTB == "강제 납치!" ==> P15001
    P15001 -- "UID 1337 신분증으로
OUTPUT 검문 무사통과!" --> ETH0

3. 무한 루프(Infinite Loop) 탈출의 두 가지 마법: UID 1337 과 127.0.0.6

위 그림을 가만히 보면 소름 끼치는 무한 루프(Infinite Loop) 함정이 두 군데 숨어 있습니다. 만약 이 함정을 피하는 규칙이 없다면 패킷은 파드 밖으로 한 발짝도 나가지 못하고 영원히 파드 안에서 빙글빙글 돌다가 죽어버립니다!

3-1. [함정 1 — 출구 무한 루프] 와 UID 1337 신분증 해법

먼저 내 앱(study-client)이 밖으로 패킷을 보낼 때를 생각해 봅시다.

1. 내 앱(curl)이 order-api:80으로 패킷을 쏩니다.
2. 커널의 OUTPUT 검문소가 이 패킷을 잡아서 같은 파드 안의 Envoy(15001번 포트) 에게 밀어 넣습니다.
3. Envoy가 패킷을 받아서 L7 로드밸런싱과 mTLS 암호화를 마친 뒤, 이제 진짜로 바깥(10.244.2.3:8080)으로 패킷을 쏩니다.
4. 🚨 위기 발생!: Envoy도 똑같이 이 파드 안에 살고 있는 프로세스입니다! 따라서 Envoy가 밖으로 쏜 패킷 역시 똑같이 커널의 OUTPUT 검문소를 지나갑니다!
5. 만약 OUTPUT 검문소가 아무 생각 없이 Envoy가 쏜 패킷마저 또 잡아서 15001번(Envoy 자신)으로 돌려보내면? Envoy → OUTPUT → 15001(Envoy) → OUTPUT → 15001(Envoy)... 무한 루프에 빠져 버립니다!

💡 Istio의 해결책: --uid-owner 1337 -j RETURN

이 문제를 풀기 위해 Istio는 리눅스의 사용자 번호(UID, User ID) 를 이용합니다.

• 내 앱 컨테이너(study-client, node 등)는 root(UID 0)나 일반 유저(UID 100, UID 1000 등)로 실행됩니다.
• 반면 istio-proxy(Envoy) 컨테이너는 쿠버네티스 배포 명세에 runAsUser: 1337 이라고 못이 박혀 있어서, 무조건 UID 1337번 계정을 달고 실행됩니다! (참고로 1337은 영미권 해커/개발자 문화에서 알파벳 LEET(Elite, 정예 요원) 를 숫자로 바꾼 유명한 이스터에그 번호입니다!)
• 그리고 istio-init은 ISTIO_OUTPUT 체인에 다음과 같은 황금 규칙을 적어 둡니다:

  -A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
  

• 해석: "지금 나가는 패킷을 만든 프로세스의 신분증(UID)을 확인(-m owner)해 봐라! 만약 UID 1337(Envoy 정예 요원) 이 만든 패킷이면, 15001번으로 납치하지 말고 즉시 이 검문소를 탈출(RETURN)시켜서 바깥 랜선(eth0)으로 내보내 주어라!"

flowchart LR
    APP["🛵 내 앱 (UID = 100)
패킷 발송"] --> CHK{"🐧 ISTIO_OUTPUT 검문소
'누가 보낸 패킷인가?'
(--uid-owner 1337)"}
    CHK -- "UID != 1337
(일반 앱이 보냄)" --> RED["🚨 ISTIO_REDIRECT
15001번(Envoy)으로 납치!"]
    RED --> ENV["🛡️ Envoy (UID = 1337)
L7 라우팅 · mTLS 암호화 후
다시 바깥으로 패킷 발송"]
    ENV --> CHK
    CHK == "UID == 1337!
(Envoy 요원이 보냄)" ==> PASS["✅ RETURN (검문 통과!)
eth0 랜선 타고 외부 파드로 출발!"]

3-2. [함정 2 — 입구 무한 루프] 와 127.0.0.6 루프백 마법

이번에는 반대로 외부에서 내 파드(order-api, 8080번 포트)로 요청이 들어올 때의 함정을 보겠습니다.

1. 외부 파드에서 order-api 파드(10.244.2.3:8080)로 패킷이 도착합니다.
2. 입구 검문소(PREROUTING → ISTIO_INBOUND)가 이 패킷을 낚아채서 Envoy의 입구 창구(15006번 포트) 로 넣습니다.
3. Envoy(UID 1337)가 암호(mTLS)를 풀고 신분증을 검사한 뒤, 이제 같은 파드 안에 있는 진짜 order-api 앱 컨테이너(8080번 포트) 에게 패킷을 토스하려고 합니다.
4. 🚨 위기 발생!: 같은 파드 안의 컨테이너끼리 통신할 때는 로컬 루프백(lo)을 타고 패킷이 이동하는데, 로컬에서 만든 패킷도 커널의 OUTPUT → ISTIO_OUTPUT 검문소를 지나갑니다!
   • 그런데 ISTIO_OUTPUT에는 "파드 안의 프로세스가 자기 자신의 파드 IP(10.244.2.3:8080)를 부를 때도 입구 검문(15006)을 거치게 하라" 는 규칙(! -d 127.0.0.1/32 -o lo ... --uid-owner 1337 -j ISTIO_IN_REDIRECT)이 들어 있습니다.
   • 만약 그냥 보내면, Envoy(15006)가 내 앱(8080)에게 토스한 패킷이 다시 15006(Envoy 자신)으로 끌려 들어가는 입구 무한 루프가 터집니다!

💡 Istio의 해결책: 출발지 IP를 127.0.0.6 으로 찍어서 보내기!

여기서 리눅스 네트워크의 아주 재미있는 성질 하나가 쓰입니다.

• 우리는 흔히 자기 자신을 가리키는 루프백(Loopback) 주소로 127.0.0.1 만 떠올리지만, 사실 국제 표준(RFC 1122)과 리눅스 커널에서는 127.0.0.1부터 127.255.255.254까지 약 1,600만 개의 IP 주소(127.0.0.0/8 전체)가 전부 내 컴퓨터 자신(lo 인터페이스) 을 가리킵니다!
• 그래서 Istio의 Envoy는 입구 창구(15006)에서 검문을 마친 패킷을 내 앱 컨테이너(8080)로 넘겨줄 때, 패킷의 출발지 IP(Source IP)를 일부러 127.0.0.6 이라는 특별한 암호 번호로 찍어서 보냅니다!
• 그리고 ISTIO_OUTPUT 검문소의 맨 첫 번째 줄(1번 규칙) 에는 다음 문장이 적혀 있습니다:

  -A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
  

• 해석: "로컬(lo)로 지나가는 패킷 중에 출발지(-s)가 127.0.0.6인 패킷은, 이미 Envoy 입구 창구(15006)에서 검문을 다 마치고 내 앱으로 배달 가는 중인 패킷이다! 절대 다시 납치하지 말고 1순위로 통과(RETURN)시켜라!"

3-3. 파드의 iptables -t nat 전체 규칙 한 줄씩 완벽 해독표

잠시 뒤 Part 02 실습에서 직접 출력해 볼 실제 iptables 규칙 전체를 한 줄도 빠짐없이 우리말로 번역한 해독표입니다. 이 표 하나면 전 세계 어떤 Istio 사이드카의 커널 규칙도 완벽히 읽을 수 있습니다!

① 입구 규칙 (PREROUTING → ISTIO_INBOUND → ISTIO_IN_REDIRECT)

② 출구 규칙 (OUTPUT → ISTIO_OUTPUT → ISTIO_REDIRECT)

4. 1세대 사이드카(Sidecar) 메시의 구조적 한계 — 왜 2세대 Ambient Mesh가 필요해졌나?

지금까지 살펴본 1세대 사이드카 아키텍처는 정말 정교하고 기발한 설계입니다. 하지만 전 세계 기업들이 파드 수백~수천 개 규모로 이 구조를 수년간 운영해 보니 4가지 뼈아픈 한계가 드러났습니다.

flowchart TB
    subgraph LIMIT["⚠️ 1세대 Sidecar 메시의 4대 운영 한계 (Part 03 Ambient Mesh의 탄생 배경)"]
        direction LR
        L1["1️⃣ 리소스 중복 낭비
파드 1,000개면 Envoy도 1,000개!
각 Envoy마다 전체 클러스터 xDS 지도를
중복 보유해 메모리 수십 GB 소모"]
        L2["2️⃣ 라이프사이클 강결합
Envoy 보안 패치 하나만 하려 해도
전사 비즈니스 파드 1,000개를
전부 롤링 재시작해야 함!"]
        L3["3️⃣ 기동/종료 순서 꼬임 (Race Condition)
Job/배치 파드가 할 일 끝내고 종료돼도
istio-proxy가 안 꺼져서 파드가
NotReady/Running에 걸리는 현상"]
        L4["4️⃣ 과도한 L7 파싱 비용
단순히 암호화(mTLS)만 필요한 파드도
무조건 무거운 L7 Envoy 전체를
사이드카로 띄워야 함"]
    end

1. 메모리와 CPU의 $O(N)$ 중복 낭비: 파드가 500개 떠 있으면 똑같은 Envoy 프로세스도 500개가 뜹니다. 더 큰 문제는 500개의 Envoy가 저마다 클러스터 전체의 xDS 지도 사본을 자기 메모리에 들고 있어서 메모리 사용량이 기하급수적으로 늘어납니다.
2. 프록시 업그레이드 = 비즈니스 앱 전체 재배포: 사이드카는 내 비즈니스 파드 안에 한 몸으로 들어 있습니다. 따라서 Istio(Envoy) 버전을 1.31.2에서 1.31.3으로 올리려면, 멀쩡히 잘 돌고 있는 비즈니스 파드 수백 개를 전부 강제로 재시작(rollout restart) 해야 합니다.
3. 배치 작업(Job / CronJob)과의 충돌: 5분 동안 데이터를 집계하고 꺼져야 하는 쿠버네티스 Job 파드에 사이드카가 붙으면, 내 배치 컨테이너는 성공(Completed)하고 꺼졌는데 옆자리의 istio-proxy 컨테이너는 혼자 계속 살아 있어서(READY 1/2) Job이 영원히 끝나지 않는 유명한 골칫거리가 발생합니다.
4. 불필요한 L7 비용 강제: 단순히 "파드끼리 통신할 때 도청만 막자(L4 mTLS 암호화)"가 목적인데도, 무조건 무거운 L7 Envoy 프록시를 모든 파드에 다 넣어야 했습니다.

핵심 요약

Part 02 핵심 정리
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
① 사이드카 주입   kubectl apply 시 kube-apiserver의 3단계 검문소(MutatingAdmissionWebhook)가
                 istiod를 호출해 YAML에 'istio-init'과 'istio-proxy'를 자동으로 끼워 넣음.
② istio-init     본 컨테이너보다 먼저 실행되는 초기화 컨테이너(InitContainer).
                 NET_ADMIN 권한으로 파드 netns에 iptables NAT 규칙만 깔고 1초 만에 종료됨(최소 권한 원칙).
③ 패킷 납치 포트  • 밖에서 들어오는 패킷: PREROUTING → ISTIO_INBOUND → 15006번(virtualInbound)
                 • 안에서 나가는 패킷:   OUTPUT     → ISTIO_OUTPUT  → 15001번(virtualOutbound)
                 • 원래 목적지는 커널 conntrack에 보관되며 Envoy가 SO_ORIGINAL_DST로 조회!
④ 무한 루프 방지  • 출구 루프 방지: Envoy는 'UID 1337'로 실행되며, --uid-owner 1337 규칙으로 즉시 RETURN!
                 • 입구 루프 방지: Envoy(15006)가 내 앱(8080)에 토스할 때는 출발지를 '127.0.0.6'으로 찍어 RETURN!
⑤ 1세대의 한계    파드마다 Envoy가 뜨는 메모리 중복·앱 재시작 강제·Job 종료 안 됨 문제
                 → 이를 해결하기 위해 사이드카 없는 2세대 Ambient Mesh(Part 03)가 탄생!

참고 자료

공식 문서:

• Istio Traffic Routing & iptables 원리: https://istio.io/latest/docs/ops/deployment/requirements/#ports-used-by-istio
• Kubernetes Dynamic Admission Control (MutatingAdmissionWebhook): https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

네비게이션